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Abstract — We propose a modeling framework for generating 
security protocol specifications. Tlie generated protocol 
specifications rely on the use of a sequential and a semantical 
component. The first component defines protocol properties such 
as preconditions, effects, message sequences and it is developed 
as a WSDL-S specification. The second component defines the 
semantic aspects corresponding to the messages included in 
the first component by the use of ontological constructions and 
it is developed as an OWL-based specification. Our approach 
was validated on 13 protocols from which we mention: the 
IS09798 protocol, the CCITTX.509 data transfer protocol and 
the Kerberos symmetric key protocol. 
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I. Introduction 

Security protocols are widely used today to provide secure 
communication over insecure environments. By examining the 
literature we come upon various security protocols designed 
to provide solutions to specific problems [1]. With this large 
amount of protocols to chose from, distributed heterogenous 
systems must be prepared to handle multiple security proto- 
cols. 

Existing technologies, such as the Security Assertions 
Markup Language [3] (i.e. SAME) or WS-Security |2| provide 
a unifying solution for the authentication and authorization is- 
sues through the use of predefined protocols. By implementing 
these protocols, Web services authenticate users and provide 
authorized access to resources. However, despite the fact that 
existing solutions provide a way to implement security claims, 
these approaches are rather static. This means that in case of 
new security protocols, services must be reprogrammed. 

In this paper we propose a more flexible solution to this 
problem by developing a security protocol specification gen- 
eration framework based on existing Web service technologies 
such as WSDL-S |8| and OWL |10|, aiming at the automatic 
discovery and execution of security protocols. 

A security protocol specification is a description of the 
protocol messages exchanged by participants and of the mech- 
anisms related to the construction and processing of messages. 
By inspecting the literature we come upon various forms of 
specifications H, ||5l, each specification being specifically 
designed for a task. 

Based on this observation, in the process of developing a 
new specification we first formulate a set of requirements. 



Because the proposed specification includes a description of 
the messages exchanged by participants, which is also one 
of the goals of the well-known informal specification, we 
consider the informal specification as the starting point of the 
construction process. Based on the formulated requirements, 
we identify two components: the message sequential specifi- 
cation, or more briefly SEQ-S, and the semantic specification, 
or more briefly SEM-S. 

The first component is designed as a WSDL-S specifica- 
tion which includes the sequence of messages that must be 
executed. For each message component an annotation is pro- 
vided in order to link the component with the corresponding 
semantic information. 

The second component is designed as an ontological spec- 
ification by using OWL. An ontology is a "formal, explicit 
specification of a shared conceptualization" [11 1, consisting of 
concepts, properties (i.e. relations) and restrictions. Ontologies 
are part of the semantic Web technology, which associates se- 
mantic descriptions to Web services. Each message component 
from the protocol is represented as a concept in a hierarchical 
structure. In order to provide processing information, domain- 
range properties are defined for each concept. 

The rest of the paper is structured as follows. In section |ll] 
we provide a description of the proposed framework. In section 
[III] we present some of our experimental results. In section [TV| 
we relate our work to others. We end with a conclusion and 
future work in section |V] 

II. The proposed framework 
A. Requirements 

The proposed framework must guarantee the construction of 
a complete security protocol specification. The basic require- 
ments that must be satisfied are extracted from the informal 
specification. These include the explicit specification of proto- 
col participants, message directions, cryptographic algorithm 
classes and message component types. 

In order for participants to implement and execute protocols 
based on the generated specifications, the above-mentioned 
requirements are not enough. We also need to include several 
requirements for describing internal mechanisms such as con- 
structing, processing and verifying messages. The resulting 
additional requirements include, among others, specifying 



the cryptographic parameters and processing operations for 
constructed and processed message components. 

Based on these requirements we identified two specification 
components: the message sequence specification, or SEQ-S, 
and the semantic specification, or SEM-S. 

B. SEQ-S structure 

The message sequence specification has been developed 
as a WSDL-S specification. The WSDL-S specification in- 
herits the structure of WSDL. It provides, in addition to 
WSDL, semantic annotation possibilities through the use of 
the wssem:modelReference attribute. In SEQ-S, the WSDL-S 
sections are maintained and used without any change. 

For each protocol participant a WSDL-S specification is 
constructed. Because of this, each WSDL-S specification will 
contain only one portType section and one binding section. 
The portType section provides an abstract group of opera- 
tions. Each operation contains a reference to a message and 
an attribute containing the communication direction of that 
message (i.e. input or output). 

In addition to providing semantics to each message, we 
use the wssemiprecondition and wssem:effect tags to specify 
semantic information related to the preconditions needed to be 
satisfied in order to execute the protocol and effects that are 
activated if the protocol is executed. 

C. SEM-S structure 

Preconditions, effects and XML schema elements are anno- 
tated in SEQ-S with references to concepts from the semantic 
specification (SEM-S). SEM-S is constructed as an ontology 
consisting of several smaller ontologies. In order to satisfy the 
requirements formulated in the previous sections we identified 
7 ontologies based on which the semantic specification is 
constructed. 

In the design of these ontologies we followed the principles 
proposed in fTTl. As in any design process, we used a 
repetitive design and implementation in order to model the 
requirements of as many protocols as possible. The resulting 
ontologies are the starting point for constructing the semantic 
specification of a security protocol. Figure [T] shows the core 
ontology of SEM-S. 



properties are applied on all constructions. From these prop- 
erties we mention: isOfType, isEncrypted, isStored, isVerified, 
isExtracted, hasSymmetricAlgorithm or hasKey. 

In the remaining of this sub-section we construct a formal 
ontology model used in the definition process of the proposed 
rules. The ontology model is defined as follows. 

Definition 1: An ontology model (OM) is a triplet 
(CONC, PROP, INST), where CONC is the set of 
concepts defined for the ontology, PROP is the set of 
properties and INST is the set of all instances. An element 
from PROP is a pair (a, [3), where a is a unique id and (3 
is a syntactic construction denoting the property name. 

In order to handle elements from an OM, we define the 
following mapping functions: 

• domain : PROP CONC to map the domain concept 
corresponding to a given property; 

• range : PROP CONC to map the range concept 
corresponding to a given property; 

• prop : CONC PROP* to map the set of properties 
for which the given concept is a domain; 

• parent : CONC CONC to map the parent of a 
given concept; 

. subcon : CONC CONC* to map the set of concepts 
for which the given concept is a parent concept; 

• rnincard : PROP ^ N to map the minimum cardinality 
for a given property; 

• rnaxcard : PROP ^ N to map the maximum cardinal- 
ity for a given property. 

The construction of SEM-S is based on a set of 13 rules 
we identified using a repetitive design and implementation of 
specifications. Because of space considerations in this section 
we only present rules that are the most relevant 

Processing rules. Rules from this category provide a set 
of guiding lines to model terms and protocol operations as 
concepts and properties such that processing of terms is made 
possible. 

For example, the next rule states that for every concept 
from the KnownTerm sub-ontology there must be an isOfType 
property defined. 
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Fig. 1. Core ontology of SEM-S 

In the process of constructing SEM-S, the proposed sub- 
ontologies are extended with concepts and properties. The 
concepts are specific to each protocol, however, the defined 



Rulel. For every sub-concept of KnownTerm that is 
not a sub-concept of a cryptographic concept there is an 
isOfType property defined. Formally, 

Vc € subcon(KnownTerm) if 
J^p' e prop{parent{c)) : 

name{p) = SymmEncrypted ,then3p G prop{c) : 
name{p) = isOfTypeA 
mincard(p) = maxcard(p) — I. 

Cryptographic rules. The rules from this category require 
that for each generated term (e.g. symmetric key, random 
number) or cryptographic term (e.g. symmetric encryption, 
hash, signature), generation or construction properties are 



also specified. 



ComunicBtionTerm 



Rule2. For every sub-concept of GeneratedTerm with 
the RandomN umber property defined, there is a hasLength 
property. Formally, 

Vc G suhcon{GeneratedTerm) if 3p G prop{c) : 
name{p) = RandomN umber then 3p' G prop{c) : 

name{p') — hasLengthA 

mincard{p') — maxcard{p') — 1. 

Storage rules. In order to model storage modules from 
which keys, certificates or tokens are extracted we use the 
LoadingModule sub-ontology. 

RuleS. For every sub-concept of LoadedTerm there is an 
isLoaded property defined. Formally, 

\fc G subcon{LoadedTerm) . 3p G prop{c) : 

name{p) — isLoadedA 

mincard{p) — maxcard{p) = 1. 



D. Example construction 

In order to provide an example usage of the previously 
defined framework we provide a partial construction of the 
sequential and semantic specification for the initiator role from 
the "BAN concrete Andrew Secure RPC". 

By examining the informal specification we conclude that 
participant A is the initiator of the protocol. For this par- 
ticipant, we must define two outgoing and two incoming 
messages. The goal of the protocol is the exchange of the 
session key K. The resulting partial SEQ-S specification is 
given in figure [2] 



<xsd : element name^" Ms gl Request " > 
<xsci : complexType> 
<xsd: sequence> 

<xsci : element name^ "Participant A" type^"xsci: string" 

wssem : modelRef erence^" . . . /SecProt . owl#Sent_A" /> 
<xsd : element name^" Random" type^"xsd:base64Binary" 
wssem:modelReference^" . . . /SecProt . owl#Sent_Na/> 
</xsd : sequence> 
</xsd: complexType> 
</xsd: element > 

<xsd : element name^"Msg2Response " > 
<xsd : complexType> 
<xsd: sequence> 

<xsd : element name^"EncTerml " type^"xsd : base64Binary" 

wssem:modelReference^" . . . /SecProt . owl#EncTerml"> 
</xsd : element > 
</xsd: sequence> 
</xsd: complexType> 
</xsd: element> 

<wsdl: operation name^"Msgl "> 

<wsdl : output message^" tns : MsglRequest " /> 
</wsdl : ope rat ion > 
<wsdl : operation name^"Msg2 "> 

<wsdl : input message^"tns :Msg2Response"/> 
</wsdl : ope rat ion > 

<wssem : effect name^" SessionKey Exchange" 

wssem : modelRef erence^" ... /SecProt . owl#SessionKey " / > 



Fig. 2. SEQ-S example schema, precondition and effect 
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Fig. 3. CommunicationTerm sub-ontology 
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Fig. 4. Discovered terms modeled as concepts 



The SEM-S construction process starts by examining the 
SEQ-S specification from which the concepts that must 
be added to the CommunicationTerm sub-ontology are ex- 
tracted. The resuhing CommunicationTerm and KnownTerm 
sub-ontologies are given in figure |3] and figure |4] respectively, 
where interrupted lines denote properties. 

III. Experimental results 

For our experiments, we developed over 38 WSDL-S and 38 
OWL specifications corresponding to initiator and respondent 
protocol roles. The WSDL-S specifications were constructed 
using Eclipse's web service package |6J while the OWL 
specifications were constructed using the well-known ontology 
editor. Protege [14|. 

The goal of our experiments was to prove that the specifica- 
tions contain sufficient information for participants to execute 
the described protocols and at the end of the execution process 
the protocol goals are achieved. 

In order to execute the specifications, messages were en- 
coded and transmitted according to the constructions provided 
by the WS-Security standard |2|. In the experiments we con- 
ducted, participants downloaded the specification files from a 
public server and they were able to execute the protocols based 
only on the received descriptions. The participants hardware 
and software configurations: Intel Dual Core CPU at 1.8GHz, 
1GByte of RAM, MS Windows XP. 



TABLE I 

Protocol execution timings 



Protocol 


S-PR. 


M-CON. 


M-PR. 


Total 


participant 


(ms) 


(ms) 


(ms) 


(ms) 


BANInit. 


14.58 


11.81 


3.68 


30.08 


BAN Resp. 


14.03 


2.86 


1.62 


18.52 


IS09798 Init. 


13.07 


35.784 


23.30 


72.16 


IS09798Resp. 


13.51 


6.876 


12.24 


32.63 


Kerb. Init. 1 


22.63 


0.83 





23.47 


Kerb. Init. 2 


12.61 


0.55 


1.58 


14.76 


Kerb. Init. 3 


2.23 


3.34 


0.94 


6.52 


Kerb. Resp. 1 


19.28 





0.41 


19.69 


Kerb. Resp. 2 


10.81 


3.379 


1.67 


15.87 


Kerb. Resp. 3 


5.25 


11.41 


3.59 


20.26 



Part of the experimental results are given in table |l] where 
the values correspond to milliseconds. The S-PR column 
denotes the specification processing time, the M-CON column 
denotes the message construction time (for output messages) 
and the M-PR column denotes the message processing time 
(for input messages). The table contains two two-party proto- 
cols ("BAN concrete Andrew Secure RPC", or more simply 
BAN, and IS09798) and one three-party protocol (Kerberos). 
The performance differences between the BAN and IS09798 
protocols are due to the fact that IS09798 makes use of 
public key cryptography, while BAN uses only symmetric 
cryptography. 

IV. Related work 

In this section we describe approaches we found in the 
literature that mostly relate to our proposal. 

An approach that aims at the automatic implementation of 
security protocols is given in lfT3l . This approach uses a formal 
description as a specification which is executed by participants. 
The proposed specification does not make use of Web service 
technologies, because of which inter-operability of systems 
executing the given specifications becomes a real issue. In 
addition, because our approach uses the ontology model, it 
benefits of several properties specific to ontologies, such as 
semantic properties, extendability or reusability of ontologies 
developed by others. 

Another automated security protocol implementation ap- 
proach is proposed in f7|. The specification in this case is 
constructed as an XML document from which the code is 
automatically generated. The resulting code is then compiled 
and executed by participants. Because of this aspect, our 
proposal is more dynamic in the sense that applications can 
download and execute new protocols based on the developed 
specifications automatically, without having to stop program 
execution. 

The authors from lfT2l propose a security ontology for 
resource annotation. The proposed ontology defines concepts 
for security and authorization, for cryptographic algorithms 
and for credentials. This proposal was designed to be used 
in the process of security protocol description and selection 
based on several criteria. In contrast, our ontologies, have a 
more detailed construction. For example, the ontology from 
lfT2l defines a collection of cryptographic algorithms, however. 



it does not define the algorithm mode, which is a more 
implementation-specific information. In addition, we did not 
only propose an ontology, but also a set of rules to construct 
a specification. 

There have been several other security ontologies proposed 
||9l , ifTSl . Because they do not relate to the specification of 
security protocols, they can not replace our proposal, but only 
complete it with additional concepts. 

V. Conclusions and future work 

We proposed a framework for generating security protocol 
specifications. Our proposal generates two components: a 
message sequential and a semantic component. The first one 
is implemented through the use of WSDL-S while the second 
one through OWL. 

In order to validate our proposal we constructed over 38 
specifications for well-known protocols from the literature 
(e.g. SSL, Kerberos) and tested them for automatic execution 
on client and server programs. 

As future work we intend to create a tool for the auto- 
matic transformation of regular informal specifications into the 
specifications proposed in this paper based on the described 
framework. 
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